跳到主要内容

以 SLO 为导向的故障处理流程

最后于 更新

SLO(Service Level Objective) 即服务级别目标,是定义服务质量和可用性的一种指标。 更多关于 SLO 介绍可参考：SLO简介

为什么要可观测性要围绕着 SLO 展开？​

通过数据驱动和SLO定义，量化服务质量，根本上提升服务可靠性，使团队具备专家视角处理风险。​

围绕 SLO 来展开可观测性工作，可以帮助用户将注意力从庞杂的指标数据中解放出来，通过量化服务质量，基于数据驱动和 SLO 定义，从根本上提高服务可靠性，让每个团队都能具备专家视角来处置和管理风险 SLO（Service Level Objective，服务级别目标）是一种用于衡量企业或组织内部服务质量的指标。相较于传统观测指标，SLO具有以下优势：

  1. 针对性：SLO 是根据业务需求和用户期望制定的，更具针对性。传统观测指标可能过于宽泛或繁琐，不能直接反映用户关注的重点。SLO 可以帮助企业更好地满足用户需求，提高客户满意度。
  2. 简洁性：SLO 旨在衡量关键服务特性，通常不超过5个，使得指标体系更简洁。相较于传统观测指标，SLO 更易于理解、监控和沟通。
  3. 可量化：SLO 要求具备可量化的数据支持，有利于对企业内部服务质量进行客观、精确的评估。这有助于发现潜在问题，为改进服务提供依据。
  4. 动态调整：SLO 可以根据业务发展和用户需求的变化进行动态调整，更具灵活性。企业可以根据实际情况，设置合理的 SLO，确保服务质量始终符合要求。
  5. 结果导向：SLO 关注的是服务结果，而非过程。这有助于企业关注核心业务，提高工作效率。
  6. 持续改进：通过监控和分析 SLO 数据，企业可以不断优化服务流程，实现持续改进。这有助于提升企业竞争力，适应不断变化的市场环境。 总之，SLO 作为一种更具针对性、简洁性、可量化、动态调整、结果导向和持续改进的优势指标，可以帮助企业更好地监控和提升服务质量，从而满足用户需求，提高客户满意度。
  7. 围绕着 SLO 可以标准化落地 1-5-10，告警可以收敛到业务层，聚焦到处理业务层 SLO 违反的原因。只要识别 SLO 违约的原因，并在10分钟解决 SLO 违约的原因，即可落地1-5-10。

为什么要以SLO来组织告警？​

主要有以下几个原因:

  1. SLO 能够量化服务质量,定义明确的目标期望。这为告警设置提供清晰的指标和阈值。
  2. SLO 遵守情况直接关乎到用户的满意度。SLO 告警可以让服务提供方时刻关注真正重要的服务质量信号。
  3. 基于 SLO 组织告警,可以减少不必要的、与服务质量无关的告警。避免告警疲劳。
  4. 当 SLO 被违反时,说明服务已不能满足用户需求。这是服务提供方必须响应的关键信号。
  5. SLO 违反后需要快速定位根因、修复问题恢复服务。围绕 SLO 展开故障响应机制可以有效降低服务中断影响。

综上,以 SLO 为核心展开监控和告警策略,可以让服务提供方更加聚焦关键的服务质量,并在质量下降时快速响应。这提高了用户满意度,也促进服务提供方主动优化系统,从而有助于双方获益。

Kindling-OriginX 提供以SLO为导向的故障处理流程​

该处理可以简单的概括为三个步骤：

  1. SLO 异常检测，检测 SLO 是否违反。
  2. 如果 SLO 违反，生成典型的故障报告，以算法及专家经验自动组织和关联分散的监控指标、日志，自动数据降噪，最终直接生成故障根因报告。
  3. 用户参照故障根因报告，根据报告与建议指导快速完成应急处置，落地 1-5-10（1分钟发现故障，5分钟识别故障初因，10分钟完成故障恢复）

将 Kindling-OriginX 基于 SLO 导向的故障处理流程与传统故障处理流程做一对比可以发现，其能够在故障处置流程中极大的缩短 MTTR，同时能够让参与处置的人员更关注在核心问题上。 图1：Kindling-OriginX 基于SLO导向的故障处理流程

为什么使用 Kindling-OriginX 只需要关心 SLO 的告警？​

在传统的可观测性系统中，SLO 仅反映了服务层面的指标，当SLO被违反时，并不直观知道具体的根因。是后续接口错误率升高了导致，亦或是流量异常所导致，还是依赖的服务出现问题，这些都可能是导致 SLO 被违反的罪魁祸首。 在传统的可观测性系统中，需要通过额外监控每个接口错误率、流量、依赖服务健康状况、CPU 利用率，流量等其他指标，并设置告警，从而帮助快速定位根因。 Kindling-OriginX 创新的以专家智慧经验与算法自动组织可观测性数据，直接给出故障根因，帮助技术人员更好更精准的理解为什么 SLO 会被违反，不再需要通过其他指标的告警来进行额外的人工分析和决策判断。

可以只使用 Kindling-OriginX 的 SLO 告警吗？​

既然 Kindling-OriginX 这么神，是否应该直接放弃已经建立的告警体系，只使用 Kindling-OriginX 的 SLO 告警？理论上 Kindling-OriginX 成熟之时，确实可以放弃其他指标的告警，现在 Kindling-OriginX 刚刚诞生，在全球也是首创的故障根因推导技术，建议仍然保留原有的告警体系，两者共存一段时间。如果发现Kindling-OriginX 的故障报告有不准的地方，欢迎提交反馈，我们一起让 Kindling-OriginX 成熟起来，让每家公司都可以实现以 SLO 为导向的故障处理流程。